The Internet Protocol (“IP” or “TCP/IP”) has emerged as a common standard for most network communication. In previous-type network schemes, the network devices (e.g. client computers) were connected by wired connections. Each device required an IP address that identified the device's unique point of attachment to the Internet. In order to receive data packets (e.g. email messages, web pages, etc.), the client device was required to be located on the network associated with its IP address. Otherwise, the data packets would be undeliverable to the destination device. If a change was necessitated in a device's point of attachment, the device required a change in its IP address, in order to preserve its ability to communicate. Otherwise, elaborate host-specific routes had to be propagated throughout much of the Internet routing fabric resulting in considerable network administrative overhead. Furthermore, IP requires that addresses and configuration settings to be defined for each device in the network. This also results in a considerable amount of system administrative effort.
The Dynamic Host Configuration Protocol (“DHCP”) was developed to relieve the volume of system administration required to manage an IP network. With DHCP, “pools” of IP addresses are assigned to a DHCP server. These address pools are called “scopes” in protocol terminology. The addresses are then allocated to client devices by the DHCP server. In addition to assigning IP addresses, DHCP also enables the setting of required configuration parameters such as subnet, mask, default router and DNS (Domain Name System) server, as are required for TCP/IP to function properly. DHCP works across most routers and allocates IP addresses for the local subnet in which the request initiated. In this way, HCP eliminates the need to manually reconfigure a new IP address for a device that moves from one subnet to another. In this way, DHCP allows mobile client devices to move “nomadically” across subnets; however, communication is disrupted each time a new IP address is assigned to a mobile device. Another aspect of DHCP is that IP addresses can be leased for periods of time. When the address expires, the device may request a renewal. Otherwise, the IP address is put back into the “scope” of unallocated addresses, so as to recover and efficiently manage unused, available IP addresses.
The procedure for using DHCP is as follows. Upon initial activation of a DHCP client, the client sends a broadcast DHCP request packet over the network. This packet is received by a DHCP server, which then allocates an available IP address to the device from one of its scopes. Each DHCP scope is used for a different TCP/IP network subnet. A mobile client device may transmit a broadcast DHCP request on a network subnet that does not have a local DHCP server. In that case, a “relay agent” must intercept the request and forward it to the DHCP server on a different subnet. The relay agent adds information that identifies the local subnet of the mobile client. This information enables the DHCP server to identify the network subnet from which the request originated. The DHCP server then uses this information to allocate an IP address from the correct scope. The DHCP server replies to the client by allocating a IP address along with the required settings.
Typically, DHCP does not permanently allocate addresses to clients. Rather, it “leases” an address to a client for a specific time period, governed by the system administrator. When the lease expires, the client can ask the server to renew the lease. If the DHCP server does not receive a renewal request by the expiration of the lease period, it will put the address back into the scope to be reused.
In recent times, wireless mobile devices have become popular. It is desired that these devices also use the IP protocol. Because mobile devices change locations, the device may be located on either a “home” or “foreign” network subnet. Presently, each mobile device is always identified by its home address, regardless of its current point of attachment to the Internet. A standard protocol, Mobile IP, is used to forward IP packets between a mobile host on a foreign network and the home network of the mobile host. When connected away from its home network, the mobile device receives packets through a “care-of” address, which provides the is home server with information about its current point of attachment to the Internet. A “Proxy Mobile IP” entity (e.g. in a parent access point) can provide proxy Mobile IP services for an IP client that does not support Mobile IP.
A mobile host that boots on its home subnet can use DHCP to obtain a home IP address specific to its home subnet. By default, a DHCP server will allocate an IP address for the subnet where the DHCP request originates. For this reason, a mobile host that boots on a foreign subnet cannot simply broadcast a DHCP request on the local subnet to obtain an IP address for its home subnet. The Mobile IP standard requires that a mobile host must have a permanent IP address for its home subnet. Therefore, a mobile host, without an IP address, cannot use mobile IP to forward a DHCP request to a DHCP server on its home subnet because it does not have a home IP address. Therefore, a mobile device cannot use DHCP when booting on a foreign network. Thus, there is a need for a mobile host, attached to a foreign subnet, to be able to access a DHCP server to obtain an IP address for its home address.
In a previous solution to the aforementioned DHCP problem, a mobile host can send a Mobile IP Registration Request with a “home address” of zero to a “Home agent” on its home subnet. The mobile host obtains a “temporary home IP address” from the home agent. The mobile host then sends an inbound request to the home DHCP server, and from there the home DHCP server services the request. This solution assumes that the corresponding DHCP reply will be sent to a broadcast Media Access Control (MAC) address (i.e. an Ethernet address). However, the DHCP standard recommends that the DHCP reply to be sent to a unicast MAC address. A Mobile IP home agent in a router can only receive data frames with the unicast destination 802 address from the router interface. Therefore, a DHCP reply with a different unicast 802 destination address cannot be forwarded to the mobile host by the home agent.
A proposed solution to the above problem has been to enter the temporary IP address assigned to the mobile host into the “giadrr” field of a DHCP request. However, this proposal is in conflict with current DHCP/BOOTP forwarding rules. BOOTP rules require that when a BOOTP relay agent receives a request, if the “giadrr” field is zero, the BOOTP relay agent inserts its address and then forwards the request. However, if the “giadrr” field is non-zero, the BOOTP relay agent cannot forward the request. Therefore, this proposed solution will not work because the BOOTP relay agent cannot forward a BOOTP or DHCP request with a non-zero “giadrr” field, thereby limiting its practicality.
A common requirement for deploying a WLAN (wireless local area network) is to provide secure access to “guest” users using an isolated “guest” subnet. It is not practical to manually configure such guest devices with an IP address; therefore, guest devices must use DHCP to dynamically obtain an IP address. A guest subnet can be created by configuring a guest VLAN (virtual local area network) for each WLAN AP (access point). However, this solution has certain drawbacks. In this scheme, an AP cannot provide “VLAN access” to a guest subnet unless it is attached to an Ethernet switch or a VLAN trunk line. Also, VLANs tend to be localized (i.e. to a floor in a building). Therefore, the scope of a VLAN-based guest subnet may be severely limited since it is not efficient or scaleable to increase the size of a VLAN. “Proxy Mobile IP” cannot be used to bind a guest device to a secure guest subnet until the guest device obtains an IP address for that subnet. The guest device cannot use DHCP to obtain a “guest” IP address if it is attached to the network on a different subnet.
A TCP/IP application communications endpoint in a mobile (or non-mobile) client is identified by the client's IP address and a UDP or TCP protocol port. An application communications session is lost if the IP address changes. A mobile client must keep the same IP address to roam “seamlessly.” If DHCP is enabled on a Windows 2000 mobile device, the TCP/IP stack in the mobile device will release its current IP address and obtain a new IP address (via DHCP) each time the mobile device roams into a new AP service area, whether the new AP is on the same subnet or a different subnet. Therefore, the Mobile IP proxy cannot be used to keep a Windows 2000 mobile device bound seamlessly to a non-local home subnet.